Every MES-to-ERP integration works beautifully on go-live day. Material masters match, routings line up, work centers map cleanly to resources. Then six months pass. Someone adds a new UoM conversion in SAP without telling the MES team. A routing gets revised in Oracle for a cost-rollup reason that has nothing to do with the shop floor, and now the MES step sequence quietly disagrees with what the ERP thinks is the standard process. Nobody notices until an order won’t release, or worse, until it releases against the wrong routing and you’re explaining a quality deviation.
This is drift, and it’s not a one-time integration problem — it’s an ongoing data governance problem that most plants don’t staff for. With a wave of S/4HANA migrations and Oracle Fusion rollouts pushing through plants this year, a lot of existing point-to-point integrations are getting re-mapped, re-tested, and in some cases rebuilt from scratch. That’s exactly the moment drift either gets designed out for good or gets baked back in for another few years. Here’s how to do the former.
Why the initial integration was never the hard part
Building the interface — whether it’s an IDoc, an OData service, a middleware layer, or a direct API call from the MES — is a known quantity. You map fields, you test transactions, you validate a few dozen sample records, you go live. What almost nobody budgets time for is the fact that master data in ERP and MES are maintained by different people, on different schedules, for different reasons.
Engineering changes a routing in the ERP for costing purposes. Plant floor changes a work instruction in the MES for a process improvement. A planner updates a material master’s safety stock without touching the MES’s local cache of that record. None of these are wrong individually — they’re just uncoordinated, and uncoordinated changes to shared master data is the literal definition of drift. An integration moves data once, at the moment of the transaction. It does nothing to guarantee the two systems stay aligned afterward unless you build something that checks.
What actually needs to be reconciled
Not everything in your material master needs constant comparison. Focus reconciliation effort on the fields that actually drive execution decisions, because those are the ones that cause failed releases or bad output when they diverge.
- Material master: base unit of measure, UoM conversions, material status/lifecycle flag (active, phase-out, blocked), lot size and batch management indicator, procurement type, and any custom fields the MES uses for scheduling logic.
- Routings/operations: operation sequence, standard values (setup and run time), work center assignment per operation, and any control key that determines whether an operation requires confirmation or inspection.
- Work centers/resources: capacity category, available capacity, and the resource-to-work-center mapping if your MES models equipment more granularly than the ERP does.
- BOMs: component list, quantities, effective dates, and alternative/phantom BOM flags — effective dating is a frequent silent-drift source because ERPs and MES systems often don’t interpret “effective from” the same way at the moment of order creation.
For each of these, the practical move is to define a checksum or hash of the fields that matter, computed the same way on both sides, rather than trying to compare every attribute in the record. A full-record comparison generates noise from fields nobody cares about (last-changed-by, internal timestamps) and buries the signal you actually need.
Build the checksum on meaning, not on the whole record
Pick the subset of fields that determine execution behavior, concatenate them in a fixed order, hash it, and store that hash with a timestamp on both the ERP side (via a view, a CDS table in S/4HANA, or a scheduled extract) and the MES side. Reconciliation then becomes a matter of comparing hashes rather than field-by-field diffs across two different schemas — much faster, much easier to alert on, and much less likely to flag cosmetic differences as failures.
Set a reconciliation cadence that matches risk, not convenience
Different master data types drift at different rates and carry different consequences, so don’t run one blanket nightly job and call it done.
- Material masters and BOMs: daily reconciliation is reasonable for most plants — these change often enough, and the cost of a mismatch (wrong component pulled, wrong UoM on a goods movement) is high enough, that a daily batch job comparing hashes is worth the compute.
- Routings: daily or near-real-time if your ERP change process pushes routing revisions frequently; weekly is defensible if routing changes go through a slower engineering change process with its own approval gate.
- Work centers/resources: weekly is usually fine, since these change less often, but any change here has ripple effects on scheduling, so don’t stretch this past a week.
The failure mode to avoid is quarterly-or-never reconciliation — the “we’ll catch it in the audit” approach. By the time a quarterly audit finds drift, you’ve potentially been running weeks or months of production against a routing or BOM that doesn’t match what the ERP thinks is authoritative. That’s not a data hygiene problem anymore; it’s a traceability and compliance problem.
Build the alerting so someone actually looks at it
A reconciliation job that produces a log file nobody reads is theater, not governance. A few practical rules:
- Route mismatches to a named owner per data domain — material masters to a materials analyst, routings to manufacturing engineering, work centers to the plant scheduler — not to a shared inbox that becomes a graveyard.
- Distinguish severity. A UoM mismatch on an active material blocks execution and should page someone. A cosmetic description difference should land in a weekly digest, not an urgent alert, or you’ll train people to ignore all of it.
- Alert on the absence of expected changes too, not just on mismatches. If your ERP change process shows an approved routing revision that hasn’t shown up in the MES within your sync window, that’s a failure of the integration pipe itself, and it deserves its own alert distinct from a data-value mismatch.
- Log every reconciliation run, pass or fail, with a retention period long enough to support an audit. Auditors and quality investigators will ask “when did this diverge,” and “we don’t keep that history” is a bad answer to have.
What “done right” looks like
A mature setup has three properties. First, drift is detected in days, driven by a scheduled reconciliation job comparing meaningful-field checksums, not discovered during a failed order release. Second, ownership is explicit — every master data domain has a named person or role responsible for resolving mismatches, and there’s an escalation path when a mismatch sits unresolved past an agreed threshold. Third, the reconciliation logic itself is treated as a maintained asset, not a one-time script — when an S/4HANA or Oracle Fusion migration changes the underlying data model, the reconciliation job gets updated in the same project, not discovered broken three months after go-live.
If you’re in the middle of an ERP migration right now, this is the moment to insist on it. Re-mapping the integration without also rebuilding the reconciliation routine just resets the clock on the same failure you’re trying to fix.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
